Delegation Revisited Reuse Mechanisms in a Statically Typed, Expression-Oriented Language

How should code reuse be supported in a statically-typed, expression-oriented programming language? Neither functionbased reuse nor class-based inheritance provides a good solution in this setting. We question the requirements for code reuse, proposing that future work evaluate whether open recursion is really needed to support cases commonly seen in industry. In addition, we explore the design space of forwarding and delegation mechanisms, finding that there are solutions that are surprisingly expressive despite their simplicity. Function-based reuse works well at the small scale, but at the medium scale we would like to compose groups of functions and perhaps state (i.e. objects). Statically-typed inheritance-based reuse works with classes as top-level declarations, but this choice is incompatible with an expressionoriented language design. First-class classes restore expression orientation, but make static typing complex. Wyvern is a new secure object-oriented language in sore need of a code reuse functionality. Being object-oriented aficionados we discuss different ways delegation can be implemented in Wyvern exploring different possibilities similar to Jones et al. exploring inheritance [2]. 1. Reuse in a Statically-Typed, Expression-Oriented Setting An expression-oriented programming language is built primarily out of expressions that reduce to first-class values. This design provides significant expressiveness benefits compared to languages that provide some abstractions only as top-level declarations. Similarly, statically typed programming languages offer compelling benefits for understanding programs at scale and for building effective tools. A language [Copyright notice will appear here once ’preprint’ option is removed.] that combines these characteristics could offer outstanding benefits to programmers, but it has been difficult to develop a good design that can provide good code reuse while keeping the type system simple enough to be usable. The most notable prior design in this space required complex typing mechanisms such as row polymorphism to reason about first-class classes [8]. Functional languages make up some of the most successful expression-oriented languages to date, and good static type systems have been developed. However, while functions provide excellent reuse at the small scale, libraries and frameworks benefit greatly from medium-scale reuse abstractions that combine multiple functions into objects [1] and combine object descriptions using mechanisms such as inheritance. Dynamically typed object-oriented languages such as Smalltalk provide excellent expressiveness, but lack static typing. Statically-typed object-oriented languages, in contrast, have tended to support classes as top-level declarations, limiting expressiveness so that classes cannot be passed around as first-class objects, but keeping the type system relatively simple. A notable exception is Racket, which provides (gradual) static typing and first-class classes, at the cost of requiring more complex typing mechanisms such as row polymorphism [8]. In the Wyvern project, we are seeking to develop an expression-oriented language that supports good reuse facilities with a relatively simple, albeit carefully designed, static type system. We start with a pure object-oriented core that models objects as records with methods and fields as members, following Bruce et al. [3]. Our model considers classes, modules, and other extensions as simply additional convenient “sugar” that can be translated to a pure object-oriented core [6]. For example, in Wyvern’s design a “class” is simply an object with a factory method to create “instances”. To promote simplicity and expressiveness, Wyvern’s subtyping relation is structural; support for nominal types is provided thorugh a separate tagging mechanism [4]. This paper explores whether it is possible to support an expressive object-level reuse mechanism in this setting, without sacrificing the simplicity of the static type system or the expression-oriented nature of the language. To remain expression-oriented, we seek to avoid tying our reuse mech-